Columbia Kermit/kermit.zip/newsgroups/misc.19960425-19960715/[e-mail] _Thu Jun 27 15:23:44 1996.msg

Internet Message Format | 2020-01-01 | 7KB

Return-Path: [e-mail]
Received: from apakabar.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30]) by watsun.cc.columbia.edu (8.7.5/8.7.3) with ESMTP id PAA29026 for <[e-mail]>; Thu, 27 Jun 1996 15:23:43 -0400 (EDT)
Received: (from news@localhost) by apakabar.cc.columbia.edu (8.7.5/8.7.3) id PAA22192 for kermit.misc@watsun; Thu, 27 Jun 1996 15:23:41 -0400 (EDT)
Path: news.columbia.edu!lamont.ldeo.columbia.edu!zombie.ncsc.mil!news.mathworks.com!newsfeed.internetmci.com!sgigate.sgi.com!mr.net!news.mr.net!wavefront.com!news
From: [e-mail] (Mike Dorn)
Newsgroups: comp.protocols.kermit.misc,comp.os.aos
Subject: Re: File transfer between AOS/VS and MS-DOS
Date: 23 Jun 1996 21:09:25 GMT
Organization: WaveFront Communications, Inc.
Lines: 117
Distribution: inet
Message-ID: <4qkbq5$[e-mail]>
References: <[e-mail]> <4qh2ie$[e-mail]>
NNTP-Posting-Host: wf-1-6.wavefront.com
Mime-Version: 1.0
Content-Type: Text/Plain; charset=US-ASCII
X-Newsreader: WinVN 0.99.7
Xref: news.columbia.edu comp.protocols.kermit.misc:5460 comp.os.aos:764

In article <4qh2ie$[e-mail]>, [e-mail]
says...
>
>In article <[e-mail]>,
>Dong G. Kim <[e-mail]> wrote:
>: We are using Data General MV/60000 HA-1 and its OS is AOS/VS II.
>: And we use C-Kermit and MS-Kermit protocol for file transfer between two
>: systems. It is fairly well in operation but too slow to send or receive
>: a large file. Approximately, it give us 300cps performance with 28.8Kbps
>: modem. I thought, there is no solution to improve the file transfer
>: speed.
>: Recentry, I saw the FAQ list about Kermit. And I get to know Kermit is
>: not a low performance file transfer protocol.
>: It said that we can tune up the Kermit to improve the speed.
>: Especially, long packet size and multiple windows, etc.
>:
>: And I got the current version of C-Kermit and MS-Kermit now.
>: C-Kermit 5A(190) and MS-Kermit 3.14 repectively.
>: Then I tested using them.
>:
>: From AOS/VS to MS-DOS(download), it was great!! More than 4 or 5 times
>: faster than before. No retries at all. I had excited.
>:
>: But, from MS-DOS to AOS/VS(upload), I failed every times. There were too
>: many retries. Sometimes, program aborted caused by retries. Sometimes,
>: file has been trnasferred to PC with about 100 times retries.
>: You can imagine, how performance it was!
>: But, I don't know why.
>: Please help to solve this problem.
>:
>: The only changed parameters by me are as follows;
>:
>: set receive packet-length 2000
>: set block 3
>: set wind 4
>:
>It sounds like a lack of flow control.  The PC is sending bytes faster
>than the MV system can read them, and so some of the incoming bytes are
>lost before Kermit even gets a chance to read them.
>
>The same thing happens, by the way, on a Telnet connection.  AOS/VS
>C-Kermit can send files at high speed using large packet and Window sizes,
>but it can not receive them that way.
>
>So I think we have a lack of adequate flow control combined with a
>terminal driver that is not designed to receive large amounts of input
>(regardless of the communication method).
>
>The best solution is to enable a good method of flow control.  Start
>Kermit this way:
>
>  ) char/on/hifc/hofc
>  ) x kermit
>  C-Kermit> set flow keep
>
>This tells AOS/VS to enable RTS/CTS flow control on your login port, and
>"set flow keep" tells Kermit not to try to change the flow control on the
>port.  Of course RTS/CTS must also be enabled on the modem that is
>connected to the port.
>
>If that doesn't work, then try using Xon/Xoff software flow control:
>
>  ) char/on/ifc/ofc
>  ) x kermit
>  C-Kermit> set flow xon/xoff
>
>In this case you must enable LOCAL Xon/Xoff flow control in the modem.
>
>If you are still having trouble, then try using a smaller packet size
>and/or window size when sending to AOS/VS.  Remember, the rule is:
>
>  For any given connection, there is an optimum combination
>  of packet and window size.
>
>If you make it smaller, the transfer will go unnecessarily slow.  If you
>make it bigger there will be errors.  The nice thing about Kermit is that
>it has commands to let you control every aspect of its operation and
>configure optimally for every connection.
>
>By the way, most of the above is covered in the manual, "Using C-Kermit",
>in the file transfer section and in the AOS/VS appendix.
>
>Finally, you might want to look at the new C-Kermit 6.0.192 Beta test,
>which is available for AOS/VS as well as UNIX and VMS.  It is in the
>kermit/test directory tree on kermit.columbia.edu.
>
>- Frank

Remember also that DG's serial I/O does not work the same way it does on a PC
or Unix box: reads & writes are done as requests that are submitted at i/o bus
speeds to an external intelligent preprocessor (IAC,ITC, etc) which actually
performs the serial i/o at whatever baud rate, using its own separate
resources & ring buffers.  The off-loaded processor performs all character
echo, cursor positioning, simple editing and delimiter detection without help
from the main CPU.  This works fine when sending--if the progam (Kermit)
requests a transmit of a large packet of data, the os will simply split it
into pieces to send to the IAC, and send the next piece as soon as one piece
has made it into the ring buffer.  When receiving, however, you get a totally
different story.  Depending on how the Kermit program running on the DG is
written, it may be completely impossible for you to receive a packet larger
than the input ring buffer size (usually 128 bytes, unless you sysgened that
IAC for a different size buffer).  Suggest you use as large a size as
practical for DG->PC transmission, keep it under 128 for PC->DG.  If your
need for Kermit xfers are limited to a few specific serial ports, you can
re-gen that particular device to give most of the ring buffer space to the one
port, and keep the packet size below that value.  (See manuals or release
notice for your current rev of VSII for max buffer memory on your specific
serial device.)

-Good luck!
----------------------------------------------------------------
Mike Dorn                    [e-mail]
Little Canada, Minnesota
The fundamental economic problem for most Americans is not that
their taxes are too high, but that their wages are too low.
----------------------------------------------------------------